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INTRODUCTION 

The  testing  and  checkout  of  production  software  often  con- 
sumes upwards  of  60  percent  of  tlx-  effort  tl.  .1  got-  info  the 
development  of  the  system.’  The  ab-cnee  in  most  program- 
ming languages  ol  language  cleinenfs  -peeihcally  defined  for 
debugging  programs  contributes  to  the  time  and  effort  in- 
volved in  the  checkout  of  systems  tine  to  programiiiers  h:r. - 
ing  to  use  various  techniques  to  improvise  debugging  code. 
This  was  especially  true  of  the  19GS  COBOL  Standard*  in 
that  there  were  no  language  elements  dedicated  to  the  de- 
bugging ami  proving  e*  'i  reef  ness  of  programs. 

The  purpose  of  this  paper  is  to  explore  tire  concepts  and 
language  constructs  introduced  into  the  1974  COBOL  Stand- 
ard3 as  the  Debug  Module.  What  this  module  has  done  for 
the  revised  COBOL  Standard  is  to  provide  a means  by  which 
the  user  can  describe  his  debugging  algorithm  at  the  source 
level.  This  includes  the  conditions  under  which  data  items 
and  procedures  are  to  be  monitored  during  execution  of  an 
object  program. 

For  the  purposes  of  this  paper,  implementor  provided 
techniques  will  be  for  the  most  part  ignored.  This  is  due  to 
the  wide  number  of  verbs  and  the  various  techniques  which 
have  emerged  .as  a result  of  a lack  of  any  formal  definition 
for  debugging  source  statements.  The  specifications  presented 
in  X3.23-19743  should  provide  in  a form  of  standard  syntax 
a semartic  composite  of  impletnentoi  debugging  techniques. 
The  new  debugging  module  permits  tlie  user  to  determine 
what  to  monitor  and  what  information  should  he  provided 
to  the  programmer  for  the  actual  debugging  of  the  program. 

COBOL  DEBUGGING  WITH  XT 23- 1968 
* (AMERICAN  NATIONAL  STAX  DARI)  COBOL) 


Prior  to  the  revised  COBOL  Standard,  there  were  no  ex- 
plicit procedures  for  specifying  what,  debugging,  if  any, 
|vou’d  lake  place  during  the  execution  of  a COBOL  program. 
|tltliougli  not  designated  as  such,  there  are  language  elements 
pi  X3. 23-1 90S  that  can  lie  used  for  debugging.  The  DIS- 
PLAY statement,  for  example,  causes  low  volume  data  to  lie 
transferred  to  a specific  output  device.  By  strategically 


placing  DISPLAY  statements  in  a source  program  the  user 
could  attempt  to  follow  the  logic  of  the  program  a-  execution 
took  place.  This  could  be  accomplished  In  DISPLAYing  a 
proccdure-namc,  oi  n data-name  and  its  < (intents. 

PROCEDI  UE-XAMK-1. 

DISPLAY  “PROCEDl'RE-XAMl.-l”  UPON 
PRINTER. 

NOTE:  THE  ABOVE  STATEMENT  INDICATES 
THA  I THIS  PROCEDURE  WAS  EXECUTED. 
MOVE  000000  TO  COUNT-B 
ADD  1 TO  COUNT-B. 

DISPLAY  “COD.XT-B  = " COUNT-B  UPON 
PRINTER. 

The  above  sequence  of  statements  would  show,  in  (be 
form  of  output  to  the  printer,  that.  PROCEDURE-NAME- 1 
was  executed  each  time  control  was  pas.-ed  to  that  set  of 
procedures.  A few  statements  later  the  contents  of  the  dutn- 
itom  COUNT-B  would  he  provided.  Execution  of  the  DIS- 
PLAY statements  would  result  in  the  following  printed 
output : 


PROCEDURE-NAME-1 
COUNT-B  - 000001 


This  method  of  (raring  a program’s  execution  is  crude  at 
best,  and  prone  to  error.  For  example,  once  a program  has 
been  debugged  and  is  ready  to  be  placed  in  a production 
mode,  one  hardly  wants  either  the  debugging  information 
provided  or  the  overhead  in  the  form  of  the  object  code 
generated  due  to  the  presence  of  the  debugging  statements. 
Therefore  the  source  code  used  for  debugging  the  program 
must  be  removed.  This  change  in  the  source  program  could 
result  in  errors  licing  introduced  into  the  program  (either 
syntax  or  logic)  which  could  necessitate  additional  testing 
Another  consideration  in  the  discarding  of  debugging 
statements  is  the  maintenance  which  might  be  required  dur- 
ing the  life  of  the  program.  If  the  requirements  for  the  pro- 


W 


3t4  National  Computer  Conference,  1976 


grain  change,  the  source  program  will  have  to  he  modified 
and  the  need  for  debugging  and  testing  arises  again.  The 
rcintroduetnm  of  the  source  statements  necessary  to  accom- 
pli h the  del  nigging  of  the  program  once  again  could  intro- 
duce syntax  and  or  logic  errors.  One  solution  to  the  problem 
is  to  control  the  execution  of  the  source  code  for  debugging 
sessions  by  the  use  of  conditional  statements  associated  with 
each  debugging  statement: 

IF  DEBUC-ItEQUIHE.MKNT  EQUAL  TO  “YES” 
DISPLAY  "C’OUXT-B- ” COUXT-B  UPOX 
PHIXTEU. 

'1'he  debugging  code  thus  could  be  executed  when  needed, 
and  once  the  program  was  ready  for  production  the  execu- 
tion of  the  debugging  code  could  be  suppressed.  (The  control 
could  be  itt  the  form  of  a switch  setting,  parameter  card, 
value  in  the  Working-Storage.)  However,  the  overhead 
problems  would  s * ill  exist;  the  larger  program  size  due  to  the 
debugging  object  code  being  present,  and  additional  execu- 
tion time  required  for  testing  the  debugging  requests. 

IMPLEMENTOR  EXTENSIONS  FOR 
DEBUGGING 

The.  need  for  debugging  functions  was  satisfied  partially 
by  implementors  providing  language  extensions,  in  their 
compilers,  which  were  designed  for  use  in  debugging  the 
programs,  (i  . ..  TRACE,  EXHIBIT,  MONITOR  state- 
ments etc.).  The  results  were  inconsistent  among  imple- 
mentations as  to  the  name  of  the  verb  used  and  the  amount 
of  external  control  that  was  available  relative  to  the  execu- 
tion of  the  debugging  statements.  These  inconsistencies  in 
control  included  (1)  whether  the  debugging  code  had  to  he 
removed  for  production  runs  or  the  execution  of  the  code 
could  he  controlled  at  execution  time,  as  well  as  (2)  whether 
the  generation  of  object  cotie  could  bn  suppressed  if  the  de- 
bugging statements  were  not  removed.  The  innovative  ability 
of  the  implementor  was  certainly  the  determining  factor  in 
this  situation  as  to  whether  the  implementation  was  an 
“intelligent”  implementation  or  something  with  less  sophis- 
tication. 


A brief  description  of  the  capabilities  of  the  debugging 
module  follows: 

1.  A compile  time  switch  determines  whether  the  de- 
bugging source  code  will  be  used  to  generate  object 
code. 

2 An  object  time  switch  determines,  (if  the  compile 
time  switch  caused  the  debugging  statements  to  be 
compiled)  whether  the  debugging  object  code  will  be 
executed. 

3.  Debugging  lines  are  source  statements  that  take  on 
either  the  characteristics  of  debugging  statements,  or 
comment  lines  depending  on  the  setting  of  the  compile 
time  switch. 

4.  The  USE  FOR  DEBUGGING  statement  specifies 
the  user  defined  items  that  are  to  he  monitored  hv  the 
associated  debugging  section.  The  procedural  state- 
ments in  the  debugging  section  define  the  algorithm 
by  which  debugging  w ill  take  place. 

5.  A special  register  called  DEBUG-ITEM  can  be  ac- 
cessed in  the  debugging  sections.  This  special  register 
contains  the  source  program  sequence  number  of  the 
line  in  the  source  program  that,  triggered  the  execu- 
tion of  the  debugging  section,  the  name  of  the  data  or 
procedure  or  file  name  involved,  and  other  informa- 
tion relative  to  the  referenced  item. 

DEBUG  MODULE  FUNCTIONAL 
CAPABILITIES 

The  language  elements  in  the  Debug  Module  of  (lie  revised 
national  COBOL  standard  provide  a means  by  which  the 
user  may  describe  bis  algorithm  to  suit  his  needs.  This  in- 
cludes controlling  the  conditions  under  which  data  items  or 
procedures  are  to  he  monitored  during  the  execution  of  the 
object  program.  The  decision  of  what  to  monitor  and  what 
information  to  capture  arc  explicitly  in  the  domain  of  the 
user.  The  introduction  of  the  debug  facility  merely  provides  a 
convenient  access  to  the  information  pertinent  to  debugging. 

The  compile  lime  switch 


COBOL  DEBUGGING  BASED  OX  X3.23-I974, 

tiie  revised  cobol  standard 


The  revision  to  X3.23-196X  has,  for  the  most  part,  solved 
the  above  shortcomings  by  more  realistically  providing  the 
tools  in  COBOL  for  accomplishing  debugging  in  a reasonable 
fashion. 

The  ideal  solution,  it  appears,  would  he  the  ability  to  con- 
trol, in  a way  external  to  the  object  program,  whether  the 
debugging  rode  would  be  executed.  Also,  the  ability  of  hav- 
ing the  debugging  source  code  remain  in  the  source  program 
and  only  be  compiled  when  requested  would  eliminate  the 
problem  of  source  code  changes  merely  for  debugging 
purposes. 


The  capability  exists  to  control,  from  within  the  source 
program,  whether  debugging  source  statements  are  to  be 
compiled  or  treated  simply  as  comments.  The  WITH  DE- 
BUGGING MODE  clause  is  written  ns  part  of  the  SOURCE- 
COMPUTER  paragraph  and  serves  as  the  compile  time 
switch  over  the  debugging  statements: 

SOURCE-COMPUTER.  Computer-name 
[WITH  DEBUGGING  MODE]. 

When  the  optional  WITH  DEBUGGING  MODE  clause  is 
specified  in  a source  program,  all  debugging  sections  and 
debugging  lines  are  compiled  as  regular  source  statements. 
The  absence  of  the  WITH  DEBUGGING  MODE  clause 


'I 

! ; 


* 

( 

f 

| 

i 

! 


Program  Debugging  Using  COBOL  ’74 


315 


causes  nl!  debugging  lines  and  debugging  sections  to  be 
compiled  as  t bough  they  were  comment  lines. 

The  compile  time  switch  permits  all  debugging  source  code 
to  remain  intact  in  the  source  program  and  only  be  compiled 
when  requested.  This  satisfies  the  option  of  being  able  to 
retain  all  debugging  source  code  in  the  program  for  future 
testing  or  debugging  without  having  to  suffer  the  overhead 
that  would  result  from  merely  suppressing  the  execution  of 
the  object  code  produced,  as  discussed  earlier. 


The  object  time  sicitch 

The  object  time  switch  dynamically  activates  or  deacti- 
vates the  debugging  code  inserted  by  the  compiler  based  on 
the  debugging  sections  described  in  the  declarative  portion 
of  the  Procedure  Division.  The  accessing  of  this  switch,  al- 
though dynamic,  cannot  be  accomplished  from  within  the 
program,  i.c.,  set  by  a COBOL  statement,  but  is  controlled 
outside  the  COBOL  environment.  This  will  most  likely  be 
accomplished  tluough  the  u-e  of  a parameter  specified  in  the 
operating  system  control  language. 

If  the  switch  is  ‘on’  then  execution  of  the  program  includes 
the  execution  of  all  debugging  sections  and  as  a result  any 
output  generated  by  the  debugging  algorithm  sjieoified  in  the 
program.  The  switch  can  activate  the  debugging  code  only  if 
the  compile  time  switch  was  ‘on’  (WITH  DEBUGGING 
MODE  clause  specified  in  the  Source-Computer  paragraph) 
when  the  program  was  compiled.  Had  the  compile  time 
switch  not  been  'on'  then  no  debugging  rode  would  have 
Wen  generated  and  therefore  could  not  be  activated.  The 
ability  tvi  control  the  activation  of  the  debugging  code  at. 
object  time  permits  the  running  of  the  program  (if  desired) 
with  the  debugging  code  present  but  dormant.  If  a problem 
occurs  or  spot  checking  is  needed,  the  program  could  lie  run 
with  the  object  switch  'on'  and  debugging  could  continue. 

Debugging  lines 


A debugging  line  is  any  line  with  a ‘O'  in  the  indicator 
area  (column  7)  of  a source  line.  Depending  on  the  presence 
or  absence  of  the  WITH  DEBUGGING  MODE  clause  in 
the  Source-Computer  paragraph,  the  line  would  lie  compiled 
either  as  pait  of  the  source  program  or  as  a comment  line. 
(A  comment  line  is  defined  ns  any  line  with  an  in  the  indi- 
cator area  and  is  ignored  by  the  compiler  except  for  present- 
ing it  as  part  of  the  source  listing.)  It  should  lie  noted  that, 
the  object  time  switch  has  no  effect  on  debugging  lines. 

The  contents  of  a debugging  line  must  be  such  that  a syn- 
tactically correct  program  is  formed  with  or  without  the 
debugging  lines  being  considered  ns  comment  lines.  Successive 
debugging  lines  are  permitted  and  a statement  can  lie  con- 
tinued on  successive  debugging  lines  as  long  as  it  results  in  a 
syntactically  correct  source  program  at  compile  time.  Due  to 
the  requirement  of  the  ‘D’  living  present,  in  the  indicator 
area,  character-strings  may  not  lie  broken  across  two  or 
more  di  bugging  lines. 

Debugging  lines  can  appear  anywhere  in  a source  program 


after  the.  Source-Computer  paragraph.  An  example  of  de- 
bugging lines  follows: 


COL  7 

1 

001100  PROCEDURE-NAME-1. 

0015001)  DISPLAY  “PROCEDURE-NAME-1" 

001510D  UPON  PRINTER. 

OOlflOO  MOVE  000000  TO  COUNT-B. 

001700  ADD  1 TO  COUNT-B. 

001  SOOl)  DISPLAY  “COUNT-B  - ” COUNT-B 

001810D  UPON  PRINTER. 


This  is  the  same  debugging  example  illustrated  previously 
for  the  10(iS  COBOL  Standard  using  the  DISPLAY  state- 
ment, but  here,  control  is  achieved  oxer  whether  the  coding 
will  he  considered  for  compilation  (compile  time  switch). 

Since  debug  lines  can  appear  in  both  the  Environment  and 
Data  Division,  as  well  as  the  Procedure  Division,  not  only 
procedural  statements  can  lie  associated  with  debugging, 
but  data  and  (lies  as  well.  For  example  if  the  output  from  the 
debugging  session  were  to  be  sent  to  a temporary  file  and 
examined  later  for  some  reason,  the  file  itself  could  lie  de- 
scribed in  such  a manner  that  it  would  only  be  compiled  into 
the  program  when  the  compile  time  switch  was  on. 


002000  ENVIRONMENT  DIVISION. 

003000  INPUT-OUTPUT  SECTION. 

003100D  SELECT  DEBUG-FILE  ASSIGN  TO 

TAPE. 

003200  SELECT  PAYROLL-FILE  ASSIGN 

TO  DISK. 

004000  DATA  DIVISION 

004100  FILE  SECTION 

0012001)  FD  DEBUG-FILE  LABEL  RECORDS 

0012101)  OMITTED. 

0043001)  01  DERUG-REC  PIC  X(200). 

001100  FD  PAYROLL-FILE 

001500  LABEL  RECORDS  STANDARD. 

005000  PROCEDURE  DIVISION 

005100  INITIALIZATION  SECTION 

005200  HOUSE-KEEP1 XG 

005300ID  OPEN  OUTPUT  DEBUG-FILE. 

005100  OPEN  INPUT  PAYROLL-FILE. 

0000001)  WRITE  DEBUG-REC. 

0071X101 ) CLOSE  DEBUG-FILE. 


In  (lie  above  example  a file  whieh  is  to  contain  debugging 
information,  and  all  of  the  references  to  i!  are  defined  as  D 
lines,  and  th'ir  presence  or  absence  is  controlled  through  the 
compile  time  switch. 
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The  USE  FOl!  DEM  GGIXG  statement 

For  tracing  procedure-names  and  the  tied  ivily  of  data  items, 
the  deling  line  would  he  woefully  in.idei|tiate  or  at  host 
pedestrian  in  nature.  The  extensive  tracing  of  procedures  and 
contents  of  data  items  is  accomplished  through  the  use  of 
debugging  sections. 

The  USE  FOH  DEBUGGING  statement  is  a declarative 
statement  and  defines  a debugging  section.  This  permits  the 
programmer  to  establish  a debugging  section  and  to  identify 
items  that  are  to  be  monitored  by  the  associated  debugging 
section.  The  rest  of  the  declarative  procedures  in  the  section 
detine  the  algorithm  by  which  debugging  will  take  place: 

DECLARATIVES 

DEB-1  SUCTION.  USE  FOR  DEBUG! ilXfl  ON 
ALL  PROCEDURES. 

PAH  AG-1. 

DEB-2  SECTION.  ESE  FOH  DEBUGGING  ON 
DATA-NAME-1. 


END  DECLARATIVES. 

A debugging  section  is  executed  each  time,  as  appropriate, 
that  the  named  item(s)  (whether  named  implicitly  or  ex- 
plicitly) are  referenced  elsewhere  in  the  Procedure  Division. 
A debugging  section  allows  the  user  to  provide  a set  of  pro- 
cedure's for  acting  on  the  data  provided  in  DEBUG-ITEM. 
The  contents  of  the  DEBUG  ITEM  are  updated  by  the 
debug  system  each  time  a refe  rence  is  made  to  an  item  for 
which  debugging  has  been  requested. 

The  COBOL  debugging  statements  themselves  produce  no 
debugging  output.  The  debugging  section  permits  the  user 
to  analyze  what  is  taking  place  and  selectively  take  any 
necessary  action  which  may  include  producing  printed  out- 
put. This  is  opposed  to  the  ‘shotgun’  approach  of  producing 
all  data  provided  by  the  debugging  system.  It  also  provides 
an  advantage  over  the  TRACE,  MONITOR,  EXHIBIT, 
. . . statements  in  that  not  only  is  more  information  available, 
but  it  is  provided  to  the  user  in  the  debugging  section  rather 
than  being  sent  to  a printer-destined  file.  The  user  has  the' 
ultimate  decision  as  to  what,  if  anything,  is  to  be  printed. 
The  TRACE  statement  could  be.  simulated  very  simply: 

DEB-1  SECTION.  USE  FOR  DEBUGGING  ALL 
PROCEDURES. 

DEB-PAR  \-l. 

DISPLAY  DEBUG-ITEM. 


discussion  shows  the  various  forms  of  the  USE  FOR  DE- 
BUGGING statement  that  can  be  used  and  the  effect  of 
using  each. 

The  first  option  of  the  USE  FOR  DEBUGGING  state- 
ment allows  for  the  tracing  of  the  execution  of  the  various, 
sets  of  procedures  in  the  procedure  division  (paragraph 
trace) : 


USE  FOR  DEBUGGING  ON 


(ALL  PROCEDURES'! 
\proeeduie-name.-l  • ■ • / 


There  are  two  methods  of  specifying  the  procedures  on 
which  to  trap,  as  is  shown  in  the  above  USE  statement. 
When  the  procedure-name-1  phrase  i:,  chosen,  tin  debugging 
section  is  executed  immediately  before  each  execution  of  the 
named  procedure  and  immediately  after  the  execution  of  any 
ALTER  statement,  which  references  procodurc-nnmo-1 . In 
this  case,  each  procedure-name  on  which  debugging  will 
take  place  must  be  specified  in  a USE  statement.  (A  USE 
statement  may  contain  a reference  to  more  than  one  pro- 
cedure-name.) On  the  other  hand,  if  the  ALL  PROCE- 
DURES phrase  is  specified,  then  the  above  described  action 
takes  place  for  each  procedure-name  in  the  program ; the 
only  exception  would  he  procedure-names  specified  in  de- 
bugging sections. 

The  second  option  of  the  USE  FOR  DEBUGGING 
STATEMENT  is  for  monitoring  the  activity  of  data  items 
referenced  in  the  Procedure  Division.  This  include  monitor- 
ing a data  item  cither  when  its  contents  have  been  modified 
or  each  time  it  is  referenced.  (For  the  purposes  of  this  dis- 
cussion the  term  ‘‘identifier’’  represents  a data-namc  in  a 
COBOL  program  including  all  qualifiers  necessary  to  make 
it  unique  and  all  subscripts  indexes  required  to  reference  it.) 


USE  FOR  DEBUGGING  ON 
[ALL  REFERENCES  OF]  identifier-1. 

If  the  optional  ALL  REFERENCES  phrase  is  specified, 
the  debugging  section  is  executed  for  every  statement  that 
explicitly  or  implicitly  references  identifier-1.  The  absence  of 
the  ALL  REFERENCES  phrase  causes  the  debugging  sec- 
tion to  be  executed  immediately  after  the  execution  of  any 
COBOL  statement  that  references  identifier-1  and  causes 
the  contents  of  the  data  item  referenced  by  identifier-1  to  be 
changed. 

There  are  a few  isolated  cases  in  which  an  implicit  refer- 
ence to  an  identifier  can  cause  a debugging  section  to  be  exe- 
cuted. A case  in  point  is  the  WRITE  statement  where  the 
FROM  phrase  is  used: 


The  reference  to  the  special  register  ‘DEBUG-ITEM’  is 
the  method  of  accessing  the  data  that,  is  provided  to  the  user 
by'  the  debug  system.  The  contents  of  this  data  item  will  be 
covered  fully  later,  it.  is  .sufficient  to  note  that  one  of  the 
fields  contains  the  name  of  the  procedure  that  was  just 
referenced  'entered  altered. 

There  ate  ba  ically  four  options  or  types  of  references  that 
can  act  as  triggers  in  a debugging  section.  Tin  following 


WRITE  record-name  FROM  identifier 

results  in  implicit  reference  to  identifier  in  that  it  is  moved 
to  record-name  prior  to  the  record  actually  being  written  as 
though  a MOVE  statement  had  been  used.  This  results  in 
an  implicit  reference  to  an  identifier  causing  a debugging 
section  to  be  executed. 

The  third  form  of  the  USE  FOR  DEBUGGING  state- 
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meat  is  for  referencing  file-names: 

USE  FOR  DEBUGGING  OX  filc-namc-1  . . . 

This  debugging  section  would  lx-  executed  after  any  ex- 
plicit reference  to  the  named  file,  (e.g.,  OPEX,  CLOSE, 
HEAD,  DELETE,  START).  There  is  a mild  inconsistency 
here  due  to  the  syntax  and  structure  of  the  COBOL  lan- 
guage. This  statement  will  not  cause  the  monitoring  of  all  of 
the  activity  of  the  tile  due  to  the  WHITE  and  REWRITE 
statements.  With  the  exception  of  the  WRITE  and  RE- 
WRITE statements,  all  other  statements  that  are  used  in 
fde  processing  explicitly  reference  the  file-name  (i.e.,  READ 
file-name,  OPEN"  1-0  file-name,  etc.).  The  WRITE  and 
REWRITE  statements  reference  the  record-name  for  the 
file  which  is  an  identifier.  Therefore,  in  order  to  trace  all  of 
the  activity  of  a file,  each  of  the  records  associated  with 
that  file  must  also  he  referenced  in  a USE  for  debugging. 
This  could  be  done  by  using  one  or  more  F SE  statements. 

There  is  a fourth  option  of  the  USE  FOR  DEBUGGIXG 
statement  which  is  for  use  in  debugging  programs  utilizing 
the  COBOL  teleprocessing  capability;  it  will  not  be  discussed 
in  this  paper. 

DEBUG-ITEM 

The  previous  paragraphs  described  the  method  of  estab- 
lishing a debugging  section  for  procedure-names,  identifiers, 
and  file-names.  When  a debugging  section  is  executed  (i.e., 
the  item  being  monitored  is  appropriately  affected)  the  de- 
bugging system  must  provide  the  information  necessary  for 
the  programmer  to  debug  the  program.  This  is  done  through 
a special  register  generated  by  the  compiler  when  the  compile 
time  debugging  switch  is  ‘on’.  This  special  register  is  acces- 
sible in  the  debugging  section  by  the  name  of  DEBUG- 
ITEM. 

There  arc  six  fields  subordinate  to  DEBUG-ITEM  which 
provide  the  debugging  information: 

1.  DEBUG-LINE — Contains  the  line  number  of  the 
source  line  which  caused  the  debugging  section  to  be 
executed. 

2.  DEBUG-NAME— Contains  the  first  thirty  char- 
acters of  the  name  that  caused  the  debugging  section 
to  he  executed,  e.g.,  procedure-name- 1,  identifier-1 , or 
file-name-1.  This  would  include  qualifiers  and/or 
subscripts  if  present  but  truncated  at  thirty  char- 
acters. 

3.  DEBUG-SUB-1,  DEBUG-SUB-2,  DEBUG-SUB-3— 
There  are  three  occurrences  of  this  item  which,  and  in 
the  ca.se  of  a data-name  which  was  subscripted/ 
indexed,  will  contain  the  occurrence  number  of  each 
level  of  the  referenced  table. 

4.  DEBUG-CONTEXTS  - Contains  information  rela- 
tive to  flic  name  that  caused  the  debugging  section  to 
lx:  executed. 

• Identifiers — contains  the  contents  of  the  identifier. 


• File-name— contains  spaces  except  that  after  a READ 
statement  it  contains  the  contents  of  the  record  read. 

• Procedure-names  - contains  a variety  of  information  in- 

dicating for  the  most  part  how  con- 
trol was  p.vsed  to  the  procedure- 
name  contained  in  DEBUG-ITEM: 
START  PROGRAM 
(first  paragraph). 

SORT  INPUT 
SORT  OUTPUT 
MERGE  OUTPUT 
PERFORM  LOOP 
FALL  THROUGH 
GO  TO 

USE  PROCEDURE 
(other  than  debugging). 

The  COBOL  description  of  DEBUG-ITEM  could  be  pre- 
sented as  follows: 

01  DEBUG-ITEM. 

02  DEBUG-LINE  PIC  X(G). 

02  FILLER  PIC  X VALUE  SPACE. 

02  DERUG-NAME  PIC  X (30). 

02  FILLER  PIC  X VALUE  SPACE. 

02  DEBUG-SUB-1  1’IC  S9(4)  SIGN  IS  LEADING 
SEPARATE  CHARACTER. 

02  FILLER  PIC  X VALUE  SPACE. 

02  DEBUG-SUB-2  PIC  80(4)  SIGN  IS  LEADING 
SEPARATE  CHARACTER. 

02  FILLER  PIC  X VALUE  SPACE. 

02  DEBUG-SUB  3 PIC  S<J(4)  SIGN  IS  LEADING 
SEPARATE  CHARACTER. 

02  FILLER  PIC  X VALUE  SPACE. 

02  DEBUG-CONTENTS  PIC  X(n). 

The.  X(n)  described  in  the  Picture  for  DEBUG- 
CONTKNTS  is  the  same  length  as  the  identifier  being  de- 
bugged or  in  the  ease  of  the  procedure-name  the  length  neces- 
sary to  hold  the  content  of  tin1  information  placed  there  by 
the  debugging  system. 

The  following  example  demonstrates  the  use  of  debugging 
sections  for  procedure-names  and  identifiers  as  well  as  the 
results  that  con'd  be  expected. 

EXAMPLE: 

080000  PROCEDURE  DIVISION 
000000  DECLARATIVES. 

090100  SECT1  SECTION. 

000200  USE  FOR  DEBUGGING  ON 

PARAGRAP1I-X. 

000300  DEB- 1. 

090400  DISPLAY  DEBliG-lTEM. 

090500  SECT2  SECTION. 

090000  USE  FOR  DEBUGGING  ON  COUNT-B. 

090700  DEB-2. 

000800  DISPLAY  DEBUG-ITEM. 

090900  END  DECLARATIVES. 

091000  FIRSTSECT  SECTION. 
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091100  l’AH.K i IIAI'll-1. 

091200  open  output  I’HInt  kill. 

101100  ’ MOVE  000000  TO  OOl’NT-B. 
101200  PAItAGKAPIl-X. 

101300  M)l)  000001  TO  COUXT-B. 

102100  IK  COl’NT-B  I.KSS  THAN  2 GO  TO 
PAKAGK.UTl-X. 

102200  Cl.OSL  I’ll  I XT-11  LL. 

102300  STOP  III  X. 


T!i<‘  results  of  the  above  execution  of  coding  would  be: 


DEBUG  DKBl'G-XAMK, 

LINE 

10!  100  COUXT-B 
101200  PARAGKAPH-X 
101300  COl'XT-H 
102100  PAR  AGl’AI’ll-X 
101300  COUXT-B 


DKBUG-C(  INTENTS 
000000 

KALI,  THROUGH 
000001 
GO  TO 
000002 


In  the  previous  example,  bad  the  KSK  KOR  PERUG- 
( 1 1 X ( I OX  PARAGRAPH-X  statement  contained  the  Al  l, 
PBOCEOrKES’  phrase  and  the  {'SI-  l'Olt  PL'BUGG IXG 
OX  COfXT-B  statement  contained  the  Aid,  Ki  l l 11- 
ENCES  phrase  then  the  appropriate  debugging  section 
would  have  been  executed  each  time  (3)1 'XT-11  was  refer- 
enced and  for  each  procedure-name  referenced  in  the  pro- 
gram. The  following  would  have  been  produced: 


DEBUG  DEBUG-NAME 
Id  XL 

OtniOO  PARAC.RAPII-1 
101100  COUNT-B 
101200  PAHAG11APH-X 
101300  COUXT-R 
1021(H)  COUXT-B 


1 )K  BU  G -CON  TE  X TS 


START  PllOGl!  \M 


000000 

FALL  TIIKOVG1! 
000001 
000001 


102100  PAKAGRAPII-X  GO  TO 

101300  COUXT-B  000002 

102100  CO l X'T-B  00C002 


CONCLUSION' 


W e eonclmle  this  discussion  by  ofTci  ing  several  thoughts  w ith 
regard  to  improved  software  reliability  and  increased  pro- 
grammer productivity. 

1.  The  advent  of  new  language  elements  which  are  de- 
sign! J for  debugging  in  COBOL  will  permit  consider- 
ation for  the  debugging  of  source  programs  to  be  in- 
cluded in  the  design  and  programming  of  an  applica- 
tion— not  as  an  afterthought,  e'or  knowledge  of 
potential  problem  areas  would  permit  the  inclusion  of 
both  debugging  sections  and  debug  line.-  which  could 
provide  ample  information  for  producing  an  ade- 

* <|iintcly  "debugged"  program. 

2.  The  use  of  source  program  preprocessors  and  assorted 
post  processors  including  “core  dumps"  should  be  for 
the  most  part  eliminated  from  the  li-t  of  tools  neces- 
sary for  the  debugging  of  COBOL  programs  now  that 
a high  level  of  control  can  be  accomplished  through 
the  use  of  COBOL  source  statement  elements. 
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